Return to doc.sitecore.com

How can I improve the performance of Sitecore Intranet Portal?

Q:

How can I improve the performance of Sitecore Intranet Portal? 

A:

There are a number of things you can do if you experience that one or more pages on a Sitecore Intranet Portal site are slow.

First of all, check which version of Sitecore Intranet Portal you are running on. If you are not running on the latest version, you should consider to upgrade. Each release contains performance small or large improvements, in addition to bug fixes and new features.  

Identify slow renderings and web controls
To identify which components that are slowing down the performance, Sitecore has a number of tools that you can use:
1) Use the Sitecore Debugger to see the performance of individual pages. If the IIS is logging "time-taken", you can also analyze the IIS log files to identify slow pages.
2) Use /sitecore/admin/stats.html to see the performance of all renderings and web controls (across all pages) 

Refer to the Performance Monitoring article for more information about performance troubleshooting.

Enable caching for selected components
By default, the current SIP releases has not enabled caching for any renderings.

It is strongly recommended to apply caching to common things like the top menu (must be set to VaryByData, VaryByUser), the sub menus (also VaryByData, VaryByUser), top search (VaryByUser), author (VaryByData). Notice that most of these renderings are statically placed into the Intranet.Main.html and Intranet.FrontPage.html, so the caching attributes must be applied directly in the aspx page. Use the stats.html page to identify other candidates for caching.

When enabling caching, you must add an extra event handler to the "item:save" event:

        <handler type="Sitecore.Publishing.HtmlCacheClearer, Sitecore.Kernel" method="ClearCache">
          <sites hint="list">
            <site>intranet</site>
          </sites>
        </handler>

This handler is required since SIP is running in live mode. This means that there is no publishing step (which normally clears the HTML cache). 

Using caching in this way should give a better user experience. Even if some of the heavy components remain uncached, the server should still be less loaded and thus render the heavy components faster. But the users might still experience slower renderinger times at times where frequent edits occur, since the HTML cache is cleared on each save operation.